Description

Fixes #308 — MutableInterfaceType instances escape the freeze mechanism when used exclusively as mutation return types (no corresponding query returning the same interface). This causes RuntimeException: You must freeze() a MutableObjectType before fetching its fields during schema validation, introspection, and query execution.

Root Cause

Two code paths in RecursiveTypeMapper allowed MutableInterfaceType to bypass freezing:

1. findInterfaces() created orphaned, unfrozen instances

findInterfaces() called $this->typeMapper->mapClassToType() (the underlying type mapper) instead of going through RecursiveTypeMapper::mapClassToType(). The underlying mapper (via TypeGenerator) creates a new MutableInterfaceType instance that is:

• Not registered in the TypeRegistry
• Not extended via @ExtendType
• Not frozen

Meanwhile, RecursiveTypeMapper::mapClassToType() later creates a different instance of the same type that is properly frozen and registered. This leaves webonyx holding a reference to the orphaned unfrozen instance (from ObjectType::getInterfaces()), while the TypeRegistry contains the frozen one.

Since webonyx's TypeInfo::extractTypes() processes getInterfaces() before getFields(), the unfrozen interface is discovered before the fields callback (which would trigger proper mapping) has a chance to run.

2. mapNameToType() didn't freeze MutableInterfaceType

The freeze logic in mapNameToType() handled MutableObjectType and input types but had no branch for MutableInterfaceType. If an interface type was loaded by name through the typeLoader before being mapped through mapClassToType(), it was returned in PENDING state.

Fix

1. findInterfaces(): Now calls $this->mapClassToType() (RecursiveTypeMapper's own method) before retrieving the interface type, ensuring the instance is registered, extended, and frozen through the proper pipeline.

2. mapNameToType(): Extended the freeze logic to also handle MutableInterfaceType, including applying type extensions before freezing — matching the existing pattern for MutableObjectType.

Why not the finalizeTypes() approach (#789)?

PR #789 proposes brute-force freezing all registered types in TypeRegistry::finalizeTypes() before schema creation. While well-intentioned, this doesn't address the root cause:

• findInterfaces() creates orphaned instances that are never registered in the TypeRegistry, so finalizeTypes() misses them entirely
• Types created during lazy resolution (after finalizeTypes() has already run) would still be unfrozen
• mapNameToType() still wouldn't freeze MutableInterfaceType at runtime
• It skips the extension step that mapClassToType() applies before freezing

Test Plan

• 4 new regression tests in MutationInterfaceFreezeTest:
  • Schema validation doesn't throw for mutation-only interface return types
  • Mutation execution returns correct data
  • Inline fragments on interface types in mutations work correctly
  • Introspection resolves the interface type without errors
• Tests fail on master with the exact error from Exception "You must freeze() a MutableObjectType before fetching its fields" gets thrown #308, pass with the fix
• All 493 tests pass (489 existing + 4 new)